Collection of Tools & Utilities/Collection of Tools and Utilities.iso/c/mgabra.zip/MGABRA.DOC

Text File | 1989-07-27 | 61KB | 1,557 lines

    ABRACADABRA! For Turbo C by Walt Howard Jr. 213-477-4151


    SECTION 1 INTRODUCTION

    Welcome to Magic Software's Instant Resident Utility Maker
    ABRACADABRA. Hopefully in no time at all we will be having you
    create some amazing TSR programs with a simplicity BEFORE NOW
    unheard of. We have also here at Magic coined a new term TCR
    meaning Terminate but Continue Running which describes programs
    which continue to run concurrently even while you are using the
    pc to run a main program. These are just as easy to create with
    ABRACADABRA.

    For me, writing TSRs used to be like first learning to program.
    Without a library to facilitate me or even the know how to build
    one I was somewhat in the dark. There wasn't even a book on the
    subject. I was later to learn why. The secrets of this activity
    were being guarded heavily by the few who knew them. I thought
    this was completely at odds with the hacker ethic but what could
    I do? Well after a few years of hobnobbing with these nuts,
    geniuses and boneheads, each of whom had a piece of the puzzle I
    was able to gather them all together and modularize them into
    ABRACADABRA.

    For most of you, the fact that you were even interested in this
    library guarantees you will have a fascinating time of it as
    these secrets are revealed.

    If you are already familiar with these internals you can skip
    right to the section describing the library primitives otherwise
    read on.

    SECRETS OF TSR PROGRAMMING

    What makes a TSR a TSR? Certainly NOT just the fact that it
    remains resident. Device drivers loaded in your CONFIG.SYS file
    remain resident but they are not generally considered a TSR. A
    TSR has several distinct qualities that define it.

    1. It remains in memory after initial loading from disk and can
    be instantly invoked from memory.

    2. The invocation of a TSR must be able to occur WITHIN another
    program. That's what gives them their utility value.

    3. The interrupted program can resume running after the TSR is
    switched out.

    4. An additional quality we will add for a TCR (Terminate
    Continue Running) is that it can continue to execute even after
    it has been switched out.





                                    1



    ABRACADABRA! For Turbo C by Walt Howard Jr. 213-477-4151


    When you are writing TSRs you are engaging in a limited degree of
    multitasking. ABRACADABRA lets you take it to a full program swap
    which means the ENTIRE program is switched, stack, data and all
    INCLUDING screen and any disk access related memory items.

    It is no small feat to program but all this work has been
    modularized for you in ABRACADABRA. If you have purchased the
    source code then you can follow along in the next section,
    otherwise you can skip right to the description of the
    ABRACADABRA library functions and how to use them.

    What makes it so difficult? Why isn't it easy to write TSRs?

    Actually the program which swaps programs while complex, is not
    the hardest part of this whole scenario. While complex, it is
    quite abstract and orderly because it is a transaction that
    occurs entirely between the CPU and memory. The 8086 has always
    been somewhat friendly in those terms.

    The difficulties occur as you get further into the real world
    away from the protected confines of the CPU and into the program
    jungle called MS-DOS. DOS is essentially hostile toward attempts
    at making it a multitasking program manager. So we have to do all
    kinds of greasy kid stuff to make it comply with our wishes.
    While the problem is complex, it is finite.

    The core of the problem, switching programs, is handled by simply
    saving the swapped out programs complete register set and
    replacing it with the swapped in programs registers. You can
    examine this in more detail in the source listing of the macros
    SAVPRC (save process) and RESPRC (restore process). When a
    process is put to sleep it's registers are stored in a special
    area loosely called the TASK CONTROL BLOCK (TCB). Other relevant
    data is also stored here and we'll cover that next.

    Besides the registers, there is other baggage that each program
    has attached that must also be switched. This consists of special
    data areas DOS sets up for disk access, screen contents, video
    modes, cursor position, and special interrupt addresses each
    program uses for critical error handling and control-c break
    checking.

    The unfriendly attitude DOS has regarding multitasking is very
    deeply rooted in it's structure. A quick summary of what DOS is,
    is simply a set of functions that a program can call to do
    things. In this manner it is no different than a function library
    you get with compiler type languages. It is designed however to
    be called from anywhere. You don't have to know the actual
    address of each function, you just load up your parameters and
    execute a software interrupt 21h. This gives control of the
    machine to DOS with the parameters you pass. It executes your
    desire and returns control to your program when it is done.
    However, DOS routines, like some languages, cannot handle

                                    2



    ABRACADABRA! For Turbo C by Walt Howard Jr. 213-477-4151


    overlapping calls. You must finish one before another is
    undertaken. This is because when you make a call, DOS switches
    from your program's stack to it's own internal set. Whatever is
    pushed here must be fully popped. If you try to call DOS before
    it has finished a previous cycle everything goes fine but when
    the previous cycle tries to complete it finds it's stack data has
    been trashed. This is unfortunate because in a multitasking
    environment you have programs which are all requesting DOS
    assistance at roughly the same time.

    The way around this is to check if DOS is currently executing an
    internal routine and have our programs wait until it is done
    before requesting a subsequent service. A good solution would be
    to latch onto the interrupt 21h and set a semaphore (flag)
    whenever someone went through there and turn it off when they
    came back out. That way we'd know when DOS was occupied.
    Surprisingly DOS itself does just this and that flag is available
    to our programs. There is an undocumented DOS feature which most
    programmers call "The Dos Busy Flag" or "The Dos Critical Flag".
    This flag exists at an address we can get by calling DOS function
    34h. You won't find this in any Microsoft documentation. It is
    simply listed as "Used Internally By Dos". So we get that address
    and check that flag whenever we want to access DOS and if it's
    busy we wait until it isn't.

    Because DOS is so finicky about when it can be called we cannot
    simply invoke our TSR whenever someone asks. We must be polite
    and wait until any DOS services are complete before we take over.
    To do this we have to know whether DOS is busy or not.

    Now there is another set of routines called the BIOS (BASIC INPUT
    OUTPUT SYSTEM) which is like DOS's DOS. DOS calls the BIOS when
    it needs a nice prepackaged routine to access peripheral devices.
    The BIOS has routines which are solely designed to organize
    access to various devices on the PC such as disk drives, monitors
    and clocks. The BIOS is actually stored in a chip on your pc and
    each machine manufacturer supplies a BIOS (or should) when you
    buy the machine. DOS is aptly named because it is a DISK
    OPERATING SYSTEM. It's routines are very strong in handling disk
    access but very weak in other areas. These weaknesses have made
    programming the BIOS as common as using DOS. Something that
    wasn't intended but has come about. Sort of like TSRs.

    The BIOS is particularly strong in vi